Method and apparatus for adaptive traffic management in a resource- constrained network

ABSTRACT

An electronic device may utilize or support adaptive traffic management in a resource-constrained network. The adaptive traffic management may comprise applying a multi-stage filtering to packets received by the electronic device, wherein each stage of the multi-stage filtering may comprises a validation check and a failure of any validation check of any stage when handling a packet terminates the handling of the packet. The adaptive traffic management may comprise apply an adaptive search function, whereby when the number of search responses received by the electronic device exceeds a particular maximum response threshold, one or more criteria for modifying search requests may be selected, to reduce number of expected search responses, and the modified search criteria may be applied to generated modified search command(s) that are applied in the search function.

CLAIM OF PRIORITY

This patent application is a continuation of U.S. application Ser. No.15/075,401, filed Mar. 21, 2016, which is a continuation of U.S.application Ser. No. 14/519,381, filed Oct. 21, 2014, which is adivisional of U.S. application Ser. No. 13/408,447, filed Feb. 29, 2012,now U.S. Pat. No. 8,867,370, which makes reference to, claims priorityto and claims benefit from U.S. Provisional Patent Application Ser. No.61/464,376 which was filed on Mar. 2, 2011, now expired.

The above-referenced application is hereby incorporated herein byreference in its entirety.

CROSS-REFERENCE TO RELATED APPLICATIONS/INCORPORATION BY REFERENCE

This patent application also makes reference to:

U.S. Provisional Patent Application Ser. No. 61/464,376 titled “AdvancedCommunication System for Wide-Area Low Power Wireless Applications andActive RFID” and filed on Mar. 2, 2011, now expired;U.S. Provisional Patent Application Ser. No. 61/572,390 titled “Systemfor Adding Dash7-Based Applications Capability to a Smartphone” andfiled on Jul. 15, 2011, now expired;U.S. Pat. No. 8,976,691 titled “Method and Apparatus for AdaptiveSearching of Distributed Datasets;”U.S. Pat. No. 9,042,353 titled “Method and Apparatus for Low-Power,Long-Range Networking;”U.S. Pat. No. 8,718,551 titled “Method and Apparatus for a Multi-band,Multi-mode Smartcard;”U.S. patent application Ser. No. 13/270,959 titled “Method and Apparatusfor an Integrated Antenna” and filed on Oct. 11, 2011, now abandoned;U.S. patent application Ser. No. 13/289,054 titled “Method and Apparatusfor Electronic Payment” and filed on Nov. 4, 2011, now abandoned;U.S. patent application Ser. No. 13/289,050 titled “Method and Apparatusfor Tire Pressure Monitoring” and filed on Nov. 4, 2011, now abandoned;U.S. Pat. No. 8,622,312 titled “Method and Apparatus for Interfacingwith a Smartcard;”U.S. Pat. No. 9,104,548 titled “Method and Apparatus for MemoryManagement;”U.S. patent application Ser. No. 13/354,615 titled “Method and Apparatusfor Discovering, People, Products, and/or Services via a LocalizedWireless Network” and filed on Jan. 20, 2012, now abandoned;U.S. Pat. No. 8,909,865 titled “Method and apparatus for Plug and Play,Networkable ISO 18000-7 Connectivity;”United States Patent Publication No. 2012/0209716 titled “Method andApparatus for Serving Advertisements in a Low-Power Wireless Network”and filed on Feb. 15, 2012;U.S. patent application Ser. No. 13/408,440 titled “Method and Apparatusfor Forward Error Correction (FEC) in a Resource-Constrained Network”and filed on Feb. 29, 2012, now abandoned;U.S. Pat. No. 9,191,340 titled “Method and Apparatus for Dynamic MediaAccess Control in a Multiple Access System;”U.S. Pat. No. 8,774,096 titled “Method and Apparatus for Rapid GroupSynchronization;”United States Patent Publication No. 2012/0226822 titled “Method andApparatus for Addressing in a Resource-Constrained Network;”U.S. Pat. No. 8,885,586 titled “Method and Apparatus for Query-BasedCongestion Control;”U.S. Pat. No. 9,154,392 titled “Method and Apparatus for PowerAutoscaling in a Resource-Constrained Network.”

Each of the above stated applications is hereby incorporated herein byreference in its entirety.

FEDERALLY SPONSORED RESEARCH OR DEVELOPMENT

[Not Applicable].

MICROFICHE/COPYRIGHT REFERENCE

[Not Applicable].

FIELD OF THE INVENTION

Certain embodiments of the invention relate to communications. Morespecifically, certain embodiments of the invention relate to a methodand an apparatus for adaptive traffic management in aresource-constrained network.

BACKGROUND OF THE INVENTION

Existing methods of transmitting packets, and handling received packetsresult in inefficient use of resources and/or energy. Furtherlimitations and disadvantages of conventional and traditional approacheswill become apparent to one of skill in the art, through comparison ofsuch systems with some aspects of the present invention as set forth inthe remainder of the present application with reference to the drawings.

BRIEF SUMMARY OF THE INVENTION

A system and/or method is provided for adaptive traffic management in aresource-constrained network, substantially as shown in and/or describedin connection with at least one of the figures, as set forth morecompletely in the claims.

These and other advantages, aspects and novel features of the presentinvention, as well as details of an illustrated embodiment thereof, willbe more fully understood from the following description and drawings.

BRIEF DESCRIPTION OF SEVERAL VIEWS OF THE DRAWINGS

FIG. 1 is a block diagram illustrating an exemplary communication setupcomprising a plurality of spatially-distributed, resource-constraineddevices, which may be utilized in accordance with an embodiment of theinvention.

FIG. 2 is a block diagram illustrating an exemplary electronic devicethat may support optimized packet filtering, in accordance with anembodiment of the invention.

FIG. 3A is a block diagram illustrating exemplary structure of physicallayer (PHY) packet carrying a data link layer frame, in accordance withan embodiment of the invention.

FIG. 3B is a block diagram illustrating exemplary structure of a subnetfield in a data link layer frame, in accordance with an embodiment ofthe invention.

FIG. 3C is a block diagram illustrating exemplary structure of a datalink frame utilized by a requester device in a resource-constrainednetwork to specify response criteria, in accordance with an embodimentof the invention.

FIG. 4A is a block diagram illustrating an exemplary implementation ofthe OSI model within an electronic device that may support optimizedpacket filtering, in accordance with an embodiment of the invention.

FIG. 4B is block diagram illustrating implementation of various aspectof the invention at different layers of the OSI model, in accordancewith an embodiment of the invention

FIG. 5A is a flow chart that illustrates exemplary steps for performinga multi-stage filtering process during handling of received packets, inaccordance with an embodiment of the invention.

FIG. 5B is a flow chart that illustrates exemplary steps for performingcyclic redundancy check (CRC) validation as one stage of a multi-stagefiltering process during handling of received packets, in accordancewith an embodiment of the invention.

FIG. 5C is a flow chart that illustrates exemplary steps for performingsubnet matching as one stage of a multi-stage filtering process duringhandling of received packets, in accordance with an embodiment of theinvention.

FIG. 5D is a flow chart that illustrates exemplary steps for performinglink quality assessment as one stage of a multi-stage filtering processduring handling of received packets, in accordance with an embodiment ofthe invention.

FIG. 6 is a flow chart that illustrates exemplary steps for adjustingtransmission criteria by a requester device to optimize traffic in aresource-constrained network, in accordance with an embodiment of theinvention.

DETAILED DESCRIPTION OF THE INVENTION

Certain embodiments of the invention may be found in a method andapparatus for adaptive traffic management in a resource-constrainednetwork. In various embodiments of the invention, an electronic devicemay apply multi-stage filtering to packets received by the electronicdevice. In this regard, the multi-stage filtering may comprise avalidation and/or a check in each stage of the multi-stage filtering,whereby a failure of any validation or check of any stage when handlinga packet terminates handling of the packet. Furthermore, at least onestage of the multi-stage filtering comprises a check that the packet isdestined for the electronic device, and that check that the packet isdestined for the electronic device may be determined based on subnetmasking. In this regard, subnet masking based checks may comprisecomparing subnet-related parameters embedded in the packet withsubnet-related parameters in the electronic device. The multi-stagefiltering may comprise applying in a first stage an error detectioncheck to determine whether the packet was corrupted during communicationover the physical medium. In this regard, the error detection check maycomprise a validating the packet based on cyclic redundancy check (CRC)value associated with the packet. The multi-stage filtering may alsocomprise applying, in one of the stages, a check that communication ofthe packet meets predetermined energy criteria. In this regard, checkingwhether communication of the packet meets predetermined energy criteriamay comprise validating that loss of energy associated with thecommunication is less than a preconfigured threshold. The loss of energymay be determined, for example, based on measurement of received signalstrength indication (RSSI) and original transmit power for the packet,which may be obtained from information embedded in the packet.

In an embodiment of the invention, an electronic device may determine,after reception of a plurality of search responses from a plurality ofother electronic devices, whether the number of search responses, whichwere triggered by a search request transmitted by the electronic device,exceeds a maximum response threshold. When the number of searchresponses exceeds the maximum response threshold, the electronic devicemay generate a modified search request to reduce number of expectedsearch responses, and transmit the modified search request. In thisregard, generating the modified search request may comprise adjustingtransmit power used in transmitting the modified search request. Theelectronic device may also be operable to adjust query parameters duringthe generating of the modified search request such that query parametersembedded in the modified search request are different than queryparameters embedded in the initial search request. In this regard, queryparameters may comprise one or more of: compare length, compare code,compare mask, and compare value. The electronic device may also adjustsubnet-related parameters during the generating of the modified searchrequest such that subnet-related parameters of the modified searchrequest are different than subnet-related parameters of the searchrequest. In this regard, subnet-related parameters comprise a subnetspecifier and/or a subnet mask. The electronic device may, in responseto the search responses exceeding the maximum response threshold, andprior to transmission of the modified search request, transmit one ormore frames to change the device subnet specifier stored in one or moreof the plurality of other electronic devices.

As utilized herein, “and/or” means any one or more of the items in thelist joined by “and/or”. As an example, “x and/or y” means any elementof the three-element set {(x), (y), (x, y)}. As another example, “x, y,and/or z” means any element of the seven-element set {(x), (y), (z), (x,y), (x, z), (y, z), (x, y, z)}.

FIG. 1 is a block diagram illustrating an exemplary communication setupcomprising a plurality of spatially-distributed, resource-constraineddevices, which may be utilized in accordance with an embodiment of theinvention. Referring to FIG. 1 there is shown a first device 102, seconddevices 104 ₁-104 ₁₆, and perimeters 106 ₁-106 ₃.

The first device 102 may comprise suitable logic, circuitry, interfaces,and/or code operable to transmit and receive wireless signals inaccordance with one or more wireless protocols. Exemplary protocolswhich may be supported by the device 102 may include the ISO 18000-7protocol, and protocols described in the above-incorporated U.S.Provisional Patent Application having Ser. No. 61/464,376 and filed onMar. 2, 2011. The first device 102 may be less resource-constraineddevice. In this regard, the first device 102 may be, for example andwithout limitation, a laptop computer, a desktop computer, a tabletcomputer, a smart phone, a server, a set-top box, a gateway, a basestation, a meter or code reader, or may comprise a combination of one ormore such devices.

Each of the second devices 104 ₁-104 ₁₆ may comprise suitable logic,circuitry, interfaces, and/or code operable to transmit and receivewireless signals in accordance with one or more wireless protocols,which may include the ISO 18000-7 standard, and protocols described inthe above-incorporated U.S. Provisional Patent Application having Ser.No. 61/464,376 and filed on Mar. 2, 2011. Each of the second devices 104₁-104 ₁₆ may be operable to store data (e.g., in the form of delimitedstrings of characters). At least some of the second devices 104 ₁-104 ₁₆may be more resource-constrained devices. In this regard, one or more ofthe second devices 104 ₁-104 ₁₆ may have relatively little memory,relatively little processing energy, operate on battery energy, and/ormay otherwise be constrained in terms of one or more resources. Thesecond devices 104 ₁-104 ₁₆ may comprise, for example, RFID tags,smartcards, keyfobs, cellphones, portable media players, appliances,and/or utility meters.

The second devices 104 ₁-104 ₁₆ may be located at different distancesrelative to the first device 102. Accordingly, the perimeters 106 ₁-106₃ may represent and/or delineate different zones of operations for thefirst device 102. Operating at each of the perimeters 106 ₁-106 ₃ maycorrespond to, for example, utilization of different transmit powerlevels by device 102. That is, the device 102 may utilize a firsttransmit power T₁ to communicate with devices within the first perimeter106 ₁, utilize a second transmit power T₂ to communicate with deviceswithin the second perimeter 106 ₂, and utilize a third transmit power T₃to communicate with devices within the third perimeter 106 ₃, whereinT₃>T₂>T₁.

In operation, the device 102 may communicate one or more of the devices104 ₁-104 ₁₆. In this regard, communications among the devices 102 and104 ₁-104 ₁₆ may be based on the ISO 18000-7 protocol, and/or similarprotocols such as the protocols described in the above-incorporated U.S.Provisional Patent Application having Ser. No. 61/464,376 and filed onMar. 2, 2011. Use of such protocols may be preferred for low-power, longrange communication, such as to enable RFID and like exchanges among thedevices 102 and 104 ₁-104 ₁₆. For example, at the 433 MHz band, lowpower communication based on such protocols may be in the range of1-2000 m. Establishing communications among the devices 102 and 104₁-104 ₁₆ may comprise utilizing a search mechanism to allow a device(e.g. device 102) to locate and establish connectivity with one or moreother devices (e.g. one or more of devices 104 ₁-104 ₁₆).Cross-referenced U.S. application Ser. No. 13/267,640, filed on Oct. 6,2011, provides more details on implementing and/or using adaptive searchamong a plurality of devices, such as devices 102 and 104 ₁-104 ₁₆. Forexample, the device 102 may initially search for particular one or moreof the devices 104 ₁-104 ₁₆. The search may be performed by locatingdevices having a particular string (e.g., a group of one or more ASCIIor UNICODE characters). The device 102 may generate a search requestpacket and transmit the search request packet. If the search requestpacket is transmitted at energy T₁, the search request packet may bereceived by data-bearing devices 104 ₁-104 ₄. If the search requestpacket is transmitted at energy T₂, the search request packet may bereceived by devices 104 ₁-104 ₈. If the search request packet istransmitted at energy T₃, the search request packet may be received bydevices 104 ₁-104 ₁₆. Note that the above assumes signal propagation inthe absence of interference or physical obstructions that criticallyimpair communications between the device 102 and one or more of thedevices 104 ₁-104 ₁₆.

In various embodiments of the invention, the devices 102 and 104 ₁-104₁₆ may be operable to support and/or utilize adaptive trafficmanagement, to enhance energy and/or resource utilization in thesedevices. In this regard, such adaptive traffic management mayincorporate use of intelligent and/or adaptive packet handling in thereceiving devices, such as by use of efficient and/or optimized packetfiltering, to enable identifying packets having particularcharacteristics promptly and efficiently, to facilitate discardingand/or terminating handling of these packets and doing so in a timelyand efficient manner, thus preventing unnecessary use of energy orresources. In an embodiment of the invention, adaptive packet handlingin the receiving devices may incorporate use of optimized packetfiltering, which may comprise use of a multi-level filtering scheme. Inthis regard, such multi-level filtering may be utilized to enabledetermining when a packet (or frame carried therein) meets (or fails tomeet) a plurality of corresponding conditions. These conditions may bedetermined by applying, at each level, a corresponding check orvalidation step. Some of the conditions incorporated into, and/orchecked in the multi-level filtering scheme, may be adaptively set orconfigured to force discarding packets (or frames). To further enhancethe filtering scheme, the various checks incorporated into themulti-level filtering scheme may be ordered within the multi-levelscheme in a particular order that may achieve faster resolution. Inother orders, the order of the filtering checks may be such indescending order based on likelihood of reaching a discardingdetermination—that is a first check may have the highest probabilitythat a particular packet, the second check having lesser probabilitythat the particular packet would be discarded, and so forth.

The adaptive traffic management may also incorporate use of intelligentand/or adaptive management of functions in the devices that may triggercommunication and/or exchange of packets, to enable controllingcommunication of packets in a manner that optimizes energy consumptionand/or resource utilization in the devices, and/or bandwidth or channelutilization in the network. For example, use of optimized searchfunctions and/or policies by requesting devices may enable controllingand/or limiting the amount of responses, triggered by the searchrequests communicated by the requesting devices, in accordance with theconstraints of the network and/or the capabilities—e.g., energy and/orresources—of the responding and/or the requesting devices. The searchfunction may be optimized and/or enhanced by, for example, adjusting thesearch criteria to reduce the number of responding devices that wouldmeet the search criteria and thus may communicate responses; and/or byadjusting (e.g., reducing) the transmit power used by the requestingdevice to control the search range, and thus the number of potentialresponding devices. Another adjustment may comprise modifying channelassignments in the network to prevent any particular channel(s) frombeing overloaded with response messaging while other channel(s) remainwholly or partially un-utilized—i.e., implement intelligent channelassignments to ensure balance load during search operations. These samemechanisms may also be utilized in increasing the search range and/ornumber of devices responding to search requests, such as when energyand/or resource availability in the network and/or devices improves toallow handling more responses.

FIG. 2 is a block diagram illustrating an exemplary electronic devicethat may support optimized packet filtering, in accordance with anembodiment of the invention. Referring to FIG. 2 there is shown anelectronic device 200.

The electronic device 200 may be similar to the electronic devices 102and/or 104 _(x) of FIG. 1, and may comprise suitable logic, circuitry,interfaces, and/or code that may be operable to implement variousaspects of the invention. The electronic device 200 may comprise, forexample, a host processor 202, a system memory 204, a signal processingmodule 206, a transmit front-end (FE) 210, a transmission antenna 220, aplurality of receive front-end (FE) 212 _(A)-212 _(N), and plurality ofreception antennas 222 _(A)-222 _(N).

The host processor 202 may comprise suitable logic, circuitry,interfaces, and/or code that may be operable to process data, and/orcontrol and/or manage operations of the electronic device 200, and/ortasks and/or applications performed therein. In this regard, the hostprocessor 202 may be operable to configure and/or control operations ofvarious components and/or subsystems of the electronic device 200, byutilizing, for example, one or more control signals. The host processor202 may enable execution of applications, programs and/or code, whichmay be stored in the system memory 204, for example.

The system memory 204 may comprise suitable logic, circuitry,interfaces, and/or code that may enable permanent and/or non-permanentstorage, buffering, and/or fetching of data, code and/or otherinformation, which may be used, consumed, and/or processed in theelectronic device 200. In this regard, the system memory 204 maycomprise different memory technologies, including, for example,read-only memory (ROM), random access memory (RAM), Flash memory,solid-state drive (SSD), and/or field-programmable gate array (FPGA).The system memory 204 may store, for example, configuration data, whichmay comprise parameters and/or code, comprising software and/orfirmware.

The signal processing module 206 may comprise suitable logic, circuitry,interfaces, and/or code for enabling processing of signals transmittedand/or received by the electronic device 200. The signal processingmodule 206 may be operable to perform such signal processing operationas filtering, amplification, up-convert/down-convert baseband signals,analog-to-digital conversion and/or digital-to-analog conversion,encoding/decoding, encryption/decryption, and/ormodulation/demodulation. The signal processing module 206 may beoperable and/or configured to support low-power wireless protocol, suchas ISO 18000-7, protocols described in above-incorporated U.S.Provisional Patent Application No. 61/464,376, and/or similar relatedprotocols.

The transmit FE 210 may comprise suitable logic, circuitry, interfaces,and/or code that may be operable to perform wireless transmission, suchas over a plurality of supported RF bands. The transmit FE 210 mayenable, for example, performing wireless communications of RF signalsvia the transmission antenna 220. In this regard, the transmissionantenna 220 may comprise suitable logic, circuitry, interfaces, and/orcode that may enable transmission of wireless signals within certainbandwidths and/or based on certain protocols. For example, one or moreof the transmission antenna 220 may enable transmission over the 433 MHzband, which may be suitable for ISM communication based on, for example,ISO 18000-7, protocols described in above-incorporated U.S. ProvisionalPatent Application No. 61/464,376, and/or similar related protocols.

Each of the plurality of receive FEs 212 _(A)-212 _(N) may comprisesuitable logic, circuitry, interfaces, and/or code that may be operableto perform wireless reception, such as over a plurality of supported RFbands. Each of the plurality of receive FEs 212 _(A)-212 _(N) mayenable, for example, performing wireless communications of RF signalsvia corresponding one of the plurality of reception antennas 222_(A)-222 _(N). Each of the plurality of reception antennas 222 _(A)-222_(N) may comprise suitable logic, circuitry, interfaces, and/or codethat may enable reception of wireless signals within certain bandwidthsand/or based on certain protocols. For example, one or more of theplurality of reception antennas 222 _(A)-222 _(N) may enable receptionof signals communicated over different channels within the 433 MHz band,which may be suitable for ISM communication based on, for example, ISO18000-7, protocols described in above-incorporated U.S. ProvisionalPatent Application No. 61/464,376, and/or similar related protocols.

In various embodiments of the invention, the electronic device 200 maysupport and/or implement adaptive traffic management, to enableoptimizing energy consumption and/or resource utilization in theelectronic device 200 during communications of signals. For example, theelectronic device 200 may be operable to use optimized packet handlingduring reception of signals. In this regard, the electronic device 200may be configured to implement and utilize a multi-stage packetfiltering. The electronic device 200 may also be configured to applyadaptive and/or intelligent management of at least certain functionsrelating to transmission of signals. For example, in instances where theelectronic device 200 may execute search operations, the electronicdevice 200 may be operable to use adaptive search function that mayenable controlling the number and/or characteristics of expectedresponses in accordance with energy and/or resource constraints in theelectronic device 200, and/or network limitations.

FIG. 3A is a block diagram illustrating exemplary structure of aphysical layer (PHY) packet carrying a data link layer frame, inaccordance with an embodiment of the invention. Referring to FIG. 3A,there is shown an exemplary physical layer (PHY) packet carrying a datalink layer frame, which may be structured in accordance with wirelessprotocols utilized by electronic devices that implement various aspectsof the invention. Cross-referenced U.S. application Ser. No. 13/408,453,filed on Feb. 29, 2012 (now U.S. Pat. No. 9,191,340), andcross-referenced U.S. application Ser. No. 13/408,461, filed on Feb. 29,2012 (now published as 2012/0226822) provide more details on thestructures of exemplary PHY packets and/or data link layer frames.

The data link layer (DLL) frame carried in PHY packets may comprise alength field, indicating the length of the DLL frame, a header and afooter, providing information pertaining to the frame and/or handlingthereof, and payload field. The DLL frame may also comprise a cyclicredundancy check (CRC) field 330. The header may comprise transmitequivalent isotropic radiated power (TxEIRP) field 310, which mayindicate the original transmit power applied by the transmitting devicein transmitting the packet (or frame). In other words, the TxEIRP field310 embedded in the frame header provides the receiving device withinformation pertaining to the transmit power applied by the transmittingdevice, enabling the receiving device to precisely determine theoriginal transmit power for received signals being handled by thereceiving device.

The DLL frame may also comprise a subnet field 320. The subnet field 320may be utilized in uniquely designating one or more devices as thetarget (receiving) device(s) for particular frame. Alternatively thesubnet field 320 may be set to enable all devices reachable by aparticular requesting device to accept and handle a particular frame.The subnet field is described in more details in FIG. 3B.

The cyclic redundancy check (CRC) field 330 may be used in conjunctionwith CRC operations. In this regard, CRC may provide a mechanism forperforming error-detection in a network, enabling detection (andcorrection) of accidental and unintended changes to data communicatedamong devices in the network. The CRC operation may comprise determiningparticular check values for blocks of data, and then attaching thesecheck values into the corresponding blocks (e.g. CRC field 330), at thetransmitting side. The check values are then validated, at the receivingside, to detect any corruption or modification of the data in theblocks, and/or to try to correct that corruption. The CRC functiondetermines the CRC check value for a block of data based on theremainder of a polynomial division of the content of the block. At thereceiving end, a similar calculation may be performed, and correctiveaction may be taken when data corruption is detected, such as when thecheck values (attached to the block and determined locally) do notmatch. CRC functions are typically categorized based on the length ofthe polynomial used thereby. For example, the CRC scheme applied to DLLframes structured in accordance with the current invention may be basedon a 16-bit CRC scheme (i.e., CRC16). The invention need not be solimited, however.

FIG. 3B is a block diagram illustrating exemplary structure of a subnetfield in a data link layer frame, in accordance with an embodiment ofthe invention. Referring to FIG. 3B, there is shown the subnet field 320of an exemplary data link layer frame, which may be structured inaccordance with wireless protocols utilized by electronic devices thatimplement various aspects of the invention. Cross-referenced U.S.application Ser. No. 13/408,453, filed on Feb. 29, 2012 (now U.S. Pat.No. 9,191,340), and cross-referenced U.S. application Ser. No.13/408,461, filed on Feb. 29, 2012 (now published as 2012/0226822)provide more details on the structures of exemplary data link layerframes.

The subnet field 320 may be utilized to allow configurable, data-basedfiltering of incoming frames. The subnet field 320 may comprise twosub-fields, a frame subnet specifier 320 _(A) and a frame subnet mask320 _(B). For example, the subnet field 320 may be structured as an8-bit value, with the upper 4 bits containing the frame subnet specifier320 _(A) and the lower 4 bits containing the value of the frame subnetmask 320 _(B). Values embedded into the two sub-fields of the subnetfield 320 may be utilized by devices receiving data link layer frames todetermine whether (or not) the frames are handled (or not) by thedevice. This process is described as “subnet matching.” In this regard,each device may maintain corresponding internal subnet values (i.e.,device subnet specifier and device subnet mask), which may be comparedduring subnet matching with the subnet field 320 embedded in receivedincoming frame. For example, during subnet matching the values of thesubnet specifiers (the frame and the device) are compared, such as forexact match, unless the frame subnet specifier is set to a particularvalue (e.g., 0xF) that indicates a universal acceptance of the frame.The subnet masks (the frame and the device), which may compriseself-referential bitmasks, may be applied to mask other values usedduring subnet matching. Subnet matching is explained in more detailswith respect to subsequent figures.

FIG. 3C is a block diagram illustrating exemplary structure of a datalink frame utilized by a requester device in a resource-constrainednetwork to specify response criteria, in accordance with an embodimentof the invention. Referring to FIG. 3B, there is shown an exemplary mode2 network protocol (M2NP) PDU 340 carrying therein a mode 2 queryprotocol (M2QP) command 350, which may be structured in accordance withthe present invention. Cross-referenced U.S. application Ser. No.13/408,453, filed on Feb. 29, 2012 (now U.S. Pat. No. 9,191,340), andcross-referenced U.S. application Ser. No. 13/408,461, filed on Feb. 29,2012 (now published as 2012/0226822) provide more details on M2NP PDUsand/or the M2QP commands.

The M2QP command 350 may be utilized during search operations—that is arequesting device may communicate the M2QP command 350 to trigger searchresponses from certain devices receiving the command (i.e., respondingdevices) under particular conditions. The M2QP command 350 may comprisea global query template 360 _(A) and a local query template 360 ₁₃. Bothof the global query template 360 _(A) and the local query template 360_(B) are structured using the same generic query template 360. Thesefields may be utilized during search operations, to specify actionsundertaken by receiving devices when determining whether the receivingdevices should respond to received M2QP commands or to disregard thecommand (and thus not send back a response). In particular, thereceiving devices may compare values embedded into the M2QP command 350with corresponding values maintained locally by these devices, todetermine whether (or not) to respond to the received M2QP command 350.Furthermore, various fields (and values stored therein) of the M2QPcommand 350 may specify various details and/or conditions pertaining tothe comparisons being performed in determining whether (or not) torespond. Accordingly, configuring and/or modifying various fields orvalues embedded in the M2QP command 350, such as the global querytemplate 360 _(A) and the local query template 360 _(B), may enableadjusting outcome of search functions.

In an embodiment of the invention, during adaptive traffic managementoperations, various fields of the M2QP command 350, such as is theglobal query template 360 _(A) and the local query template 360 _(B),may be modified to enable adjusting search functions being executed by arequesting device. For example, the number of receiving devices that maydecide to respond to a received M2QP command 350 may be determined byadjusting comparison related values embedded in the global querytemplate 360 _(A) and the local query template 360 _(B), such as: thecomparison length (i.e., the length, in bits, of the portion of theembedded compare value being matched); the comparison mask (a bitmaskfor masking portion of embedded compare value being matched); thecomparison value (the value being compared to a corresponding internalvalue in the devices); and/or the compare command, which may specifywhether masking is used (or not), the type of comparison (e.g. logical‘or’), and any pertinent comparison parameters. For example, to reducethe number of devices that may qualify for responding to a particularM2QP command 350, masking may be turned off (that is the whole comparevalue must be matched), and/or the type of comparison specified by thecompare command may be changed from logical ‘or’ to bitwise ‘and.’ Thismay enable a requesting device to reduce the number of responses beingcommunicated in a resource-constrained network even when the transmitpower of the requesting device (and this the search range) is keptunchanged.

FIG. 4A is a block diagram illustrating an exemplary implementation ofthe OSI model within an electronic device that may support optimizedpacket filtering, in accordance with an embodiment of the invention.Referring to FIG. 4A, there is shown the device 200 of FIG. 2.

The device 200 may be operable and/or configured to incorporate an OSImodel based implementation in accordance with the protocol described inthe above-incorporated U.S. Provisional Patent Application No.61/464,476, filed on Mar. 2, 2011. In this regard, the 7 OSI layers maybe implemented via one or more physical components of the device 200.For example, the Physical (PHY) Layer (layer 1 of the OSI model) may beimplemented via the transmit FE 210 and the receive FE 212 _(A)-212_(N); the Data Link Layer (layer 2 of the OSI model) and the NetworkLayer (layer 4 of the OSI model) may be implemented via the signalprocessing module 206; while the remaining layers, comprising theTransport Layer (layer 4 of the OSI model), the Session Layer (layer 5of the OSI model), the Presentation Layer (layer 6 of the OSI model),and the Application Layer (layer 7 of the OSI model) may be implementedvia the main processor 202.

During communications from and/or to the device 200, the seven OSIlayers may be utilized to perform different functions and/or processesfor facilitating such communications, and/or enable controlling variousaspects related thereto. In this regard, the OSI module may typically beutilized to enable performing required header/footer encapsulationand/or stripping, and may comprise exchange of data among the OSIlayers, after handling the data within each OSI layer—e.g., inaccordance with particular protocol(s). For example, each OSI layer mayattach to data received from higher OSI layer(s), headers/footersrelating to that OSI layer, such as to enable a corresponding layer in apeer device to handle the data; and may strip such headers/footers fromdata received from lower OSI layer(s), typically after utilizing theheaders/footers in handling data within that OSI layer, beforeforwarding the data to higher OSI layer(s). During OSI relatedprocessing, data may be internally exchanged among the OSI layers,and/or the physical components in which OSI layers are implemented,using data buses for example. The handling of data (e.g. encapsulationor stripping) may require buffering of data by one or more OSI layers,as demonstrated by use of transmit/receive (Tx/Rx) buffers 410 in theData Link Layer 404.

To control operations of the OSI model, the OSI layers may need toexchange data enabling configuring and/or adjustment of functions and/ormodules in the OSI layers. For example, the Physical Layer 402 mayprovide to the Data Link Layer 404 various information, shown asPHY_Ctrl_Info, which may in turn enable configuring and controlling thePhysical Layer 402 (e.g., via PHY_Config) by the Data Link Layer 404(and by higher layers operating via the Data Link Layer 404). ThePHY_Ctrl_Info may comprise status information relating to the PhysicalLayer 402, and/or to various functions or modules thereof. ThePHY_Ctrl_Info may also comprise information obtained via the PhysicalLayer 402.

Similarly, the Data Link Layer 404 may provide to the higher OSI layers406 with various information, shown as DL_Ctrl_Info, which enableconfiguring and controlling the Data Link Layer 404 (e.g., viaDL_Config) by the higher OSI layers 406. The DL_Ctrl_Info may comprisestatus information relating to the Data Link Layer 404 (and PhysicalLayer 402), and/or to various functions or modules thereof. TheDL_Ctrl_Info may also comprise information obtained via the Data LinkLayer 404. Dedicated configuration registers, such as configurationregisters 412 of the Data Link Layer 404 may be utilized to store andmaintain parameters used in effectuating requested configurations and/oradjustments.

In various embodiments of the invention, the OSI module implemented bythe device 200 may be configured and/or adjust to enable and/or supportadaptive traffic management. For example, the OSI model may beconfigured to support optimized packet handling. In this regard,implementing optimized packet handling in the OSI model may compriseadding new, dedicated functions and/or modules, and/or modifying oradjusting existing functions and/or modules performing operations thatmay affect transmission and/or reception of packets the device 200during communications. For example, the OSI model may be modified and/orconfigured to implement a multi-stage packet filtering scheme inconjunction with reception of packets. FIG. 4B describes in more detailsan exemplary incorporation of optimized packet filtering into the OSImodel.

FIG. 4B is block diagram illustrating implementation of various aspectsof the invention at different layers of the OSI model, in accordancewith an embodiment of the invention. As shown in FIG. 4B, the device 200may comprise various modules and/or processes that may be run indifferent layers of the OSI model, and may interact to facilitateperforming various functions and/or operations of the device 200.

For example, the device 200 may comprise a received signal strengthindication (RSSI) module 430, which may operate at the Physical Layer(layer 1 of the OSI model); and a link quality assessment module 440, asubnet matching module 442, and a cyclic redundancy check (CRC)validation module 444, which may operate at the Data Link Layer (layer 2of the OSI model).

The RSSI module 430 may implement RSSI measurement operations, in whichthe strength of received signals may be determined, and reported as avalue corresponding to particular relative level between the minimum andmaximum values.

The link quality assessment module 440 may implement link qualityassessment, during which certain checks are performed to determinewhether a received frame (extracted from received packet) may bediscarded, or processing of the frame is continued. In this regard,during link quality assessment, the TxEIRP field is extracted from theframe's header, and the value of detected RSSI for the frame issubtracted from the TxEIRP field to derive a corresponding link budgetutilization value. If link quality filtering is enabled (e.g., byassertion of LQ_(EN)), the frame would be discarded and Data Link Layerprocessing terminated when the derived link budget utilization value isgreater than a particular link quality threshold (shown as LQ_(thr)).The LQ_(thr) may be configurable, in a manner that enables determiningwhether a particular frame is discarded based on determination of lossof power during communication of the frame. In this regard, settingLQ_(thr) to a relatively-high value may reduce power consumptionbecause: the device may process fewer received packets (because they aredropped rather than being processed), the device may transmit fewerpackets (because there are fewer successfully-received packets torespond to), and/or the average transmit power is lower (becauseresponses are only being sent from devices which are reachable via ashort/low-attenuation path). The value of LQ_(thr) may be configuredbased, for example, on one or more of: location of the device (e.g.,determined by GPS and/or other wireless signals), type of device (e.g.,whether the device is a laptop, a smartphone, or a battery-powered tag),power source of the device (e.g., plugged-in or running on battery),remaining battery charge, which particular and/or types of the devicesare desired to be communicated with, and results of past communications(e.g., number of responses received to previous requests).

The subnet matching module 442 may implement subnet matching, duringwhich certain checks are performed to determine whether a received frame(extracted from received packet) may be discarded, or whether processingof the frame is to be continued. In this regard, during subnet matching,certain subnet-related values embedded in received frames may becompared to corresponding subnet-related values maintained internally inthe electronic device (shown as DS_(specifier) and DS_(mask)). Forexample, each frame may comprise a frame subnet specifier, which mustmatch a corresponding internally maintained device subnet specifier(DS_(specifier)) for a successful subnet matching tooccur—alternatively, successful subnet matching may result when theframe subnet specifier is a universal acceptance value. Other subnetrelated values may comprise subnet masks (both frame and device—that isDS_(mask)), and these masks may comprise bitmasks. In this regard,during subnet matching, device and frame subnet masks may be logically‘anded,’ and compared when determining whether subnet matching wassuccessful. Subnet matching is described in more details in FIG. 5C.

In an exemplary embodiment, the DS_(mask) values of devices having aparticular DS_(specifier) may be normally distributed between 0 and 15.That is, approximately 1/16^(th) of the devices may have a DS_(mask)value of 0, 1/16^(th) of the devices may have a value of 1, and so on.Accordingly, controlling the value of the FSM may enable controlling thenumber of devices which respond to a particular request. For example, anFSM of 1111 may result in all devices responding, an FSM of 0111 mayresult in half of the devices responding, an FSM of 0011 may result in ¼of the devices responding, and an FSM of 0001 may result in ⅛^(th) ofthe devices responding, and FSM of 0000 may result in 1/16^(th) of thedevices responding.

The CRC validation module 444 may implement data integrity checking,during which certain checks are performed to determine whether areceived frame (extracted from received packet) may be discarded, orprocessing of the frame is continued. In this regard, during CRCvalidation, the CRC value embedded (or attached) to particular frame iscompared to locally determined CRC value based on content of the frame.For example, when 16-bit CRC (CRC16) is utilized, when the CRC16calculation of the content of a received frame matches the CRC16 value(field 330) attached to the frame, processing of the frame (by the DataLink Layer) may continue. In an embodiment of the invention, the CRC16calculation applicable via the CRC validation module 444 may include allprevious bytes of the frame, and it may utilize the InternationalTelegraph and Telephone Consultative Committee (CCITT) CRC16 polynomial,or x¹⁶+x¹²+X⁵+x⁰ (1021) with initial value 0xFFFF.

In operation, the link quality assessment module 440, the subnetmatching module 442, and the CRC validation module 444 may be utilizedto enable performing multi-stage filtering of received packets in thedevice 200. For example, the CRC validation module 444 may be utilizedto perform a first filtering stage, in which CRC validation is applied,with the frame being discarded if CRC validation fails, and handling ofthe frame continuing if the CRC validation succeeds. The link qualityassessment module 440 may be utilized to perform a second filteringstage, in which link quality assessment is applied, with the frame beingdiscarded if link quality assessment fails, and handling of the framecontinuing if the link quality assessment succeeds. The subnet matchingmodule 442 may be utilized to perform a third filtering stage, in whichsubnet matching is applied, with the frame being discarded if subnetmatching fails, and handling of the frame continuing if the subnetmatching succeeds.

The order of functions applicable in the different stages of themulti-stage filtering scheme may be configurable. In this regard, theselective matching of particular validation functions with the variousstages of the filtering scheme may be done in a manner that bestoptimize the handling of the packet. In other words, the assignment ofthe various checks and/or validation functions performed during themulti-stage filtering may be determined based on probability of failure,with checks more likely to fail (i.e., conditions more like to be met)being performed earlier, and check less like to fail being donesubsequently. Furthermore, the ordering of the checks and/or validationsteps may also depend on evaluation of the relevance of these checks orvalidations. For example, checks or validations relating to theintegrity of the received fames and/or data carried therein may beperformed earlier, since any errors in the content may result in falseoutcomes in remaining checks. For example, because the outcome of thesubnet matching or link quality assessment may be false when the contentof frames is corrupted (altering fields or values used during thesechecks), the first stage of the multi-stage filtering may be tailored tovalidate the reliability of the frames, such as by applying the CRCvalidation as a first stage since it ensures that the content of theframes, which may comprise values used by the other checks (e.g., TxEIRP310 and frame subnet 320) are trustworthy.

FIG. 5A is a flow chart that illustrates exemplary steps for supportingoptimized packet filtering in an electronic device, in accordance withan embodiment of the invention. Referring to FIG. 5A, there is shown aflow chart 500 comprising a plurality of exemplary steps for performingmulti-stage packet filtering in an electronic device, such as device200, during reception of packet by the electronic device in aresource-constrained network.

In step 502, after a start step, CRC validation may be performed (FIG.5B) on a particular frame carried via a received packet. In step 504, adetermination whether the CRC validation was successful may beperformed. In instances where the outcome of the CRC validation is notsuccessful, the plurality of exemplary steps may terminate, with theframe being discarded, and/or handling or processing of the frame beingterminated—that is, any resources, functions and/or modules beingallocated and/or spawned for handling of the frame being released and/orterminated.

Retuning to step 504, in instances where the outcome of the CRCvalidation is successful, the plurality of exemplary steps may proceedto step 506. In step 506, subnet matching may be performed (FIG. 5C) onthe frame. In step 508, a determination whether the subnet matching wassuccessful may be performed. In instances where the outcome of thesubnet matching is not successful, the plurality of exemplary steps mayterminate, with the frame being discarded and/or handling or processingof the frame being terminated.

Retuning to step 508, in instances where the outcome of the subnetmatching is successful, the plurality of exemplary steps may proceed tostep 510. In step 510, link quality assessment may be performed (FIG.5D) on the frame.

FIG. 5B is a flow chart that illustrates exemplary steps for performingcyclic redundancy check (CRC) validation as one stage of a multi-stagefiltering process during handling of received packets, in accordancewith an embodiment of the invention. Referring to FIG. 5B, there isshown a flow chart 520 comprising a plurality of exemplary steps forperforming CRC validation as part of a multi-stage packet filteringscheme in an electronic device, such as device 200.

In step 522, after a start step, the CRC value (e.g. field 330) attachedto a frame carried in a received packet may be extracted. In step 524,CRC validation may be performed using the extracted CRC value, andlocally calculated CRC value based on the content of the frame. Ininstances where the CRC validation is successful (i.e. the CRC isvalid), the plurality of exemplary steps may proceed to step 526, wherethe processing and handling of the frame may continue (i.e., asuccessful check).

Returning to step 524, in instances where the CRC validation fails (i.e.the CRC is not valid), the plurality of exemplary steps may proceed tostep 528, where the frame may be discarded, and processing and handlingof the frame may be terminated (i.e., failed check).

FIG. 5C is a flow chart that illustrates exemplary steps for performingsubnet matching as one stage of a multi-stage filtering process duringhandling of received packets, in accordance with an embodiment of theinvention. Referring to FIG. 5C, there is shown a flow chart 540comprising a plurality of exemplary steps for performing subnet matchingas part of a multi-stage packet filtering scheme in an electronicdevice, such as device 200.

In step 542, the frame subnet specifier (FSS)—i.e., the value ofsubfield 320 _(A)—may be extracted from the frame's subnet field 320. Instep 544, a determination of whether the frame subnet specifier (FSS) isthe universal acceptance value may be performed. In this regard, aparticular value (e.g., 0xF) may be reserved for use as a default valuethat triggers bypassing the specifier matching during subnet matching inreceiving devices. In instances, where the frame subnet specifier (FSS)is the universal acceptance value, the process may jump to step 548.

Returning to step 544, in instances, where the frame subnet specifier(FSS) is NOT the universal acceptance value, the process may proceed tostep 546. In step 546, a comparison between the frame subnet specifier(FSS) and a corresponding, locally maintained (in the device) subnetspecifier (DSS) may be performed. In other words, the frame subnetspecifier (FSS) is compared against the DSS. In this regard, thecomparison may be directed to determining if the two values match. Thematching may be, but not limited to, exact matching. In instances wherethe frame subnet specifier (FSS) does not match the device subnetspecifier (DSS), the plurality of exemplary steps may proceed to step554, where the frame may be discarded, and processing and handling ofthe frame may be terminated—that is, any resources, functions and/ormodules being allocated and/or spawned for handling of the frame beingreleased and/or terminated.

Returning to step 546, in instances where the frame subnet specifier(FSS) matches the device subnet specifier (DSS), the plurality ofexemplary steps may proceed to step 548. In step 548, the frame subnetmask (FSM)—i.e., the value of subfield 320 _(B)—may be extracted fromthe frame's subnet field 320; and a combined mask value may be generatedfrom the frame subnet mask (FSM) and the corresponding, internallymaintained (in the device) subnet mask (DSM). In this regard, thecombined mask value may be generated by bitwise ‘anding’ the framesubnet mask (FSM) with device subnet mask (DSM). In step 550, acomparison between the combined mask value and the device subnet mask(DSM) may be performed. In other words, the combined mask value(generated by bitwise anding of FSM and DSM) is compared against a DSM.In this regard, the comparison may be directed to determining if the twovalues match. The matching may be, but not limited to, exact matching.In instances where the combined mask value does not match the devicesubnet mask (DSM), the plurality of exemplary steps may proceed to step554, where the frame may be discarded, and processing and handling ofthe frame may be terminated (i.e. failure).

Returning to step 550, in instances where the combined mask valuematches the device subnet mask (DSM), the plurality of exemplary stepsmay proceed to step 552, where processing and handling of the frame maycontinue (i.e. success).

FIG. 5D is a flow chart that illustrates exemplary steps for performinglink quality assessment as one stage of a multi-stage filtering processduring handling of received packets, in accordance with an embodiment ofthe invention. Referring to FIG. 5D, there is shown a flow chart 560comprising a plurality of exemplary steps for performing link qualityassessment as part of a multi-stage packet filtering scheme in anelectronic device, such as device 200.

In step 562, after start of process, a determination whether linkquality assessment is enabled may be performed. In this regard, linkquality assessment may be enabled (or disabled) by asserting (orde-asserting) a control signal or control parameters (e.g. in register),such as LQ_(EN), which may in turn activate corresponding function ormodule (e.g. link quality assessment module 340) for performing and/ormanaging power autoscaling operations. In instances where it may bedetermined that link quality assessment is not enabled the process mayterminate.

Returning to step 562, in instances where it may be determined that linkquality assessment is enabled the process may proceed to step 564. Instep 564, a determination whether a received (data link) frame comprisesa TxEIRP field may be performed. In this regard, the TxEIRP field mayindicate the equivalent isotropic radiated power (EIRP)—i.e., power—thatthe transmitting device originally utilized in transmitting the packet(or frame) which is being handled by the receiving device. In instanceswhere it may be determined that the received frame does not comprise theTxEIRP field the process may terminate.

Returning to step 564, in instances where it may be determined that thereceived frame comprises the TxEIRP field the process may proceed tostep 566. In step 566, the TxEIRP field (or value thereof) may beextracted. In step 568, the received signal strength indication (RSSI)may be determined. In this regard, the RSSI may measure the strength ofthe signal(s) carrying the packet that comprise the frame in question,as determined by the receiving device. In step 570, the link budgetutilization value may be determined, by subtracting the measured RSSIvalue from the extracted TxEIRP. In other words, the link budgetutilization value may correspond to the loss of power duringcommunication of the signals carrying the packet (frame) between thetransmitting device and the receiving device. In step 572, it may bedetermined whether the calculated link budget utilization value isgreater than a particular link quality threshold. In this regard, thelink quality threshold LQ_(thr) may be configurable value. Specifically,the LQ_(thr) parameter may be set and/or adjusted during adaptive powerautoscaling, to enable modifying signal reception sensitivity in thedevice 200. The value of the LQ_(thr) threshold, and/or any adjustmentthereof, may be dictated by the applicable power autoscaling algorithm.In instances where it may be determined that the link budget utilizationvalue is greater than the link quality threshold (LQ_(thr)), the processmay proceed to step 574, enabling handling and/or processing of theframe to continue. Returning to 572, in instances where it may bedetermined that the link budget utilization value is not greater thanthe link quality threshold (LQ_(thr)), the process may proceed to step576, where handling and/or processing of the frame may be stopped andthe frame may be discard.

In an embodiment of the invention, parameters utilized in applyingand/or controlling link quality assessment may be set and/or modified inaccordance with applicable filtering scheme used in the device 200, toadjust filtering outcome of this process. Adjusting the LQ_(thr)threshold, for example, may cause a corresponding adjustment in thedetermination whether to discard a packet or to continue processing it.In this regard, when the LQ_(thr) threshold is set to a low value,received signals communicated over links having high link budget value(i.e. large power loss) may be perceived (the signal) as beingsufficiently reliable, and packets/frames carried via such signal may beprocessed; whereas when the LQ_(thr) threshold is set to a high value,received signals communicated over links having low link budget value(i.e. small power loss) may perceived as not being sufficientlyreliable, and packets/frames carried via such signals are discarded. Thevalue of the LQ_(thr) threshold may be adjusted in accordance withapplicable multi-stage filtering scheme. In this regard, adjusting theLQ_(thr) threshold may enable modifying reception sensitivity—that issetting the LQ_(thr) threshold to a low value would enable handlingand/or processing packets/framed carried via signal communicated over alink having a particular link budget value (power loss) whereaspackets/frames, carried via similar signals communicated over link withsimilar link budget value would be discarded when the LQ_(thr) thresholdis increased

FIG. 6 is a flow chart that illustrates exemplary steps for adjustingtransmission criteria by a requester device to optimize traffic in aresource-constrained network, in accordance with an embodiment of theinvention. Referring to FIG. 6, there is shown a flow chart 600comprising a plurality of exemplary steps that may be performed by anelectronic device, such as device 200, to provide enhanced search in aresource-constrained network.

In step 602, a requesting device may initiate a search operation. Inthis regard, the search operation may comprise transmitting one or moresearch commands, such as the M2QP command 350 of FIG. 3C, wherebydevices receiving this command (the receiving devices) may determinewhether (or not) to respond to the search command. Determining whetheror not to respond to search commands may be based on compare functionsexecuted in the receiving devices, based on information embedded in thesearch command and/or information maintained locally. These values maycomprise both values that are being compared and/or parametersspecifying details and/or conditions applicable to the comparefunctions. In step 604, a determination whether the number of receivedsearch responses exceeds a maximum response threshold may be performed.In other words, the requesting device may determine whether the searchoperation performed in step 602 resulted in a large number of responsesthat may be undesirable in light of the network and/or deviceconstraints—that is whether the search triggers a number of responsesthat is deemed too large to be handled, due to bandwidth utilization inthe network (or particular channels), and/or energy consumption orresource utilization in conjunction with handling the responses. Thevalue of the maximum response threshold may be configurable, and it maybe modified based on changing conditions in the network and/or therequesting devices (e.g., freeing up of bandwidth in the network,drainage in energy supply of the requesting device, execution of otherfunctions with lower/higher priority, etc.). The maximum responsethreshold may be determined implicitly, such as based on detecting oftoo many data collisions (e.g., too many bad CRC); or explicitly, suchas if the response window is sufficiently crowded. In instances where itmay be determined that the number of responses exceeded the maximumresponse threshold, the process may terminate.

Returning to step 604, in instances where it may be determined that thenumber of responses did exceed the maximum response threshold; theprocess may proceed to step 606. In step 606, the requesting device mayselect one or more search optimization criteria for modifying the searchfunction. For example, the search optimization may comprise adjustmentof transmit power, such as by reducing transmit power to physicallynarrow the search range. Additionally or alternatively, the searchoptimization may comprise adjustments that logically narrow the searchrange—i.e. reduce the number of devices that would meet the conditionsrequired for responding to the search. Such logical narrowing of thesearch may be achieved by modifying the search command itself (e.g., byadjusting the query template parameters). The logical narrowing of thesearch may be achieved by modifying the classification and/or assignmentof devices and/or channels in the network. For example, subnetassignments may be adjusted such that smaller number of devices wouldsuccessfully pass subnet matching applicable based on the search command(e.g., the requesting device may send a multicast frame which results ina new DSS being written to some of the responding devices). Additionallyor alternatively, some receiving device(s) may be reassigned to and/orinstructed to respond on a different channel than the one(s) on whichthe search command is transmitted or specified as acceptable responsechannel(s). Similarly, different subsets of responding devices may beinstructed to respond on different channels and/or at different times.In step 608, the search optimization criteria selected in step 606 areapplied, and the search operation is re-executed with a new searchcommand being generated, in accordance with the modified criteria, andtransmitted.

While the process described in FIG. 6 is based on checking for thecondition that the number of received search responses exceeds a maximumresponse threshold, the invention need not be so limited. For example,in an embodiment of the invention, a check of whether the number ofreceived search responses reaches a minimum response threshold may alsobe performed, and the search function may be adjusted to increase therange of search, both physically (e.g., by increasing the transmitpower) and/or logically, such as by increasing the number of devicesthat would meet the conditions required for responding to the search, byadjusting the query template parameters and/or subnet related parametersfor example.

Other embodiments of the invention may provide a non-transitory computerreadable medium and/or storage medium, and/or a non-transitory machinereadable medium and/or storage medium, having stored thereon, a machinecode and/or a computer program having at least one code sectionexecutable by a machine and/or a computer, thereby causing the machineand/or computer to perform the steps as described herein for adaptivetraffic management in a resource-constrained network.

Accordingly, the present invention may be realized in hardware,software, or a combination of hardware and software. The presentinvention may be realized in a centralized fashion in at least onecomputer system, or in a distributed fashion where different elementsare spread across several interconnected computer systems. Any kind ofcomputer system or other apparatus adapted for carrying out the methodsdescribed herein is suited. A typical combination of hardware andsoftware may be a general-purpose computer system with a computerprogram that, when being loaded and executed, controls the computersystem such that it carries out the methods described herein.

The present invention may also be embedded in a computer programproduct, which comprises all the features enabling the implementation ofthe methods described herein, and which when loaded in a computer systemis able to carry out these methods. Computer program in the presentcontext means any expression, in any language, code or notation, of aset of instructions intended to cause a system having an informationprocessing capability to perform a particular function either directlyor after either or both of the following: a) conversion to anotherlanguage, code or notation; b) reproduction in a different materialform.

While the present invention has been described with reference to certainembodiments, it will be understood by those skilled in the art thatvarious changes may be made and equivalents may be substituted withoutdeparting from the scope of the present invention. In addition, manymodifications may be made to adapt a particular situation or material tothe teachings of the present invention without departing from its scope.Therefore, it is intended that the present invention not be limited tothe particular embodiment disclosed, but that the present invention willinclude all embodiments falling within the scope of the appended claims.

What is claimed is:
 1. A method, comprising: in an electronic devicecomprising a communication interface for communicating over a physicalmedium: applying multi-stage filtering to packets received by saidelectronic device, wherein: each stage of said multi-stage filteringcomprises a validation check, and a failure of any validation check ofany stage when handling a packet terminates said handling of saidpacket; and at least one stage of said multi-stage filtering comprises acheck that said packet is destined for said electronic device, and saidcheck that said packet is destined for said electronic device isdetermined based on subnet masking.
 2. The method of claim 1, comprisingapplying, in a first stage of said multi-stage filtering, an errordetection check to determine whether said packet was corrupted duringcommunication over said physical medium.
 3. The method of claim 2,wherein said error detection check comprises a validation based oncyclic redundancy check (CRC) value associated with said packet.
 4. Themethod of claim 1, comprising applying, in a stage of said multi-stagefiltering, a check that communication of said packet meets predeterminedenergy criteria.
 5. The method of claim 4, comprising validating, duringsaid checking of whether said communication of said packet meetspredetermined energy criteria, that loss of energy associated with saidcommunication is less than a preconfigured threshold.
 6. The method ofclaim 5, comprising determining said loss of energy based on measurementof received signal strength indication (RSSI) and original transmitpower for said packet, said original transmit power being obtained frominformation embedded in said packet.
 7. The method of claim 1,comprising comparing, during said subnet masking based check,subnet-related parameters embedded in said packet with subnet-relatedparameters in said electronic device.
 8. A system, comprising: anelectronic device comprising a communication interface for communicatingover a physical medium, said electronic device being operable to apply amulti-stage filtering to packets received by said electronic device,wherein: each stage of said multi-stage filtering comprises a validationcheck, and a failure of any validation check of any stage when handlinga packet terminates said handling of said packet; and at least one stageof said multi-stage filtering comprises a check that said packet isdestined for said electronic device, and said check that said packet isdestined for said electronic device is determined based on subnetmasking.
 9. The system of claim 8, wherein said electronic device isoperable to apply, in a first stage of said multi-stage filtering, anerror detection check to determine whether said packet was not corruptedduring communication over said physical medium.
 10. The system of claim9, wherein said error detection check comprises a validation based oncyclic redundancy check (CRC) value associated with said packet.
 11. Thesystem of claim 8, wherein said electronic device is operable to apply,in a stage of said multi-stage filtering, a check that communication ofsaid packet meets predetermined energy criteria.
 12. The system of claim11, wherein said electronic device is operable to validate, during saidchecking of whether said communication of said packet meetspredetermined energy criteria, that loss of energy associated with saidcommunication is less than a preconfigured threshold.
 13. The system ofclaim 11, wherein said electronic device is operable to determine saidloss of energy based on measurement of received signal strengthindication (RSSI) and original transmit power for said packet, saidoriginal transmit power being obtained from information embedded in saidpacket.
 14. The system of claim 8, wherein said electronic device isoperable to compare during said subnet masking based check,subnet-related parameters embedded in said packet with subnet-relatedparameters in said electronic device.
 15. A system, comprising: anelectronic device that comprises a communication interface forcommunicating over a physical medium, said electronic device beingoperable to: determine, after reception of a plurality of searchresponses from a plurality of other electronic devices, whether thenumber of search responses exceeds a maximum response threshold, whereinthe search responses are triggered by a first search request transmittedby said electronic device; when the number of search responses exceedssaid maximum response threshold, generate a modified search request toreduce number of expected search responses; and transmit said modifiedsearch request.
 16. The system of claim 15, wherein said generating saidmodified search request comprises adjusting transmit power used whentransmitting said modified search request.
 17. The system of claim 15,wherein said electronic device is operable to adjust query parametersduring said generating of said modified search request such that queryparameters embedded in said modified search request are different thanquery parameters embedded in said first search request.
 18. The systemof claim 17, wherein said query parameters comprise one or more of:compare length, compare code, compare mask, and compare value.
 19. Thesystem of claim 15, wherein said electronic device is operable to adjustsubnet-related parameters during said generating of said modified searchrequest such that subnet-related parameters of said modified searchrequest are different than subnet-related parameters of said searchrequest.
 20. The method of claim 19, wherein said subnet-relatedparameters comprise a subnet specifier and/or a subnet mask.